Relationships between Common Graphical Representations Used in System Engineering

Most system engineers today use graphical representations of a system to communicate its functional and data requirements. The most commonly used representations are the Function Flow Block Diagram (FFBD), Data Flow Diagram (DFD), N2 Chart, IDEF0 Diagram, and Behavior Diagram (BD). This paper discusses the characteristics of each and shows how they are related. When analyzed in the context of specifying functional control and data modeling, it appears that the FFBD and DFD representations are limiting, special cases of the Behavior Diagram. The N2 Chart has the same capability as the DFD, with a more formal format. The IDEF0 is essentially an N2 Chart with some control definition (no constructs) capability. The IDEF0 has the capability to indicate the allocation of functions to system components. Thus, the Behavior Diagram features comprise a “parent/unified” set of graphical system representations. To achieve the same level of specification completeness, you would have to use an integrated set of the FFBD and one of the data models or augment the FFBD with a graphical representation of the data model, as was done at TRW (then called Function Sequence Diagrams, FSDs). BACKGROUND Over the past several years, system engineers have evolved to a few graphical representations to present the functional and data flow characteristics of their system design. The most common of these are the Function Flow Block Diagram (FFBD), Data Flow Diagram (DFD), N2 (N-Squared) Chart, IDEF0 Diagram, and Behavior Diagram (BD). All of these graphical representations allow the engineer to decompose the functional and/or data models hierarchically. The objective of this paper is to analyze the representation capability of these graphic “languages” to see if there is a unifying view available. TERMINOLOGY Let us introduce two terms that we use in describing the conditions that allow/cause a function to begin execution. Considering the control and data environment, a function can begin execution if it is both enabled (by control) and triggered (by data). In the case where there is no data trigger specified, a function begins execution upon being enabled. A function is enabled if the function(s) that precede it in the control flow specification have completed execution (e.g., satisfied their completion criteria). A function is triggered when the required stimulus data item becomes available to the function. We are not concerned here with other execution requirements (such as the availability of necessary resources) that could be represented by either control or data structures as necessary. FUNCTION FLOW BLOCK DIAGRAM The Function Flow Block Diagram (FFBD) was the first to be favored by system engineers and continues to be widely used today (DSMC 1989, Blanchard and Fabrycky 1990). Figure 1 shows a sample FFBD. An FFBD shows the functions that a system is to perform and the order in which they are to be enabled (and performed). The order of performance is specified from the set of available control constructs shown in Figure 2. The control enablement of the first function is shown by the reference node(s) which precede it, and the reference node(s) at the end of the function logic indicate what functions are enabled next. The Proceedings of the SETE2000 Conference FFBD also shows completion criterion for functions as needed for specification (for example, the exits for the multiple-exit function in Figure 1). The FFBD does not contain any information relating to the flow of data between functions, and therefore does not represent any data triggering of functions. The FFBD only presents the control sequencing for the functions. DATA FLOW DIAGRAM The Data Flow Diagram (DFD), shown in Figure 3, shows required data flow between the functions of a system (DeMarco 1979). This representation is widely used by software engineers and serves as the basis of many software engineering methodologies and automated tools. The figure shows that data repositories, external sources, and external sinks can also be represented by DFDs. However, Ref. 1 Serial Function AND AND 2 Function in Concurrency 3 Multi-exit Function OR IT IT 4 Function in Iterate OR OR 5 Function in Select Construct 6 Function 2 in Select Construct 7 Output Function Ref. cc#1